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Abstract - The National Aeronautics and Space 
Administration (NASA) and the Department of Defense 
(DoD) are planning Space System of Systems (SoS) to 
address the new challenges of space exploration, defense, 
communications, navigation, Earth observation, and 
science. In addition, these complex systems must provide 
interoperability, enhanced reliability, common interfaces, 
dynamic operations, and autonomy in system management. 
Both NASA and the DoD have chosen to meet the new 
demands with high data rate communication systems and 
space Internet technologies that bring Internet Protocols 
(IP), routers, servers, software, and interfaces to space 
networks to enable as much autonomous operation of those 
networks as possible. These technologies reduce the cost of 
operations and, with higher bandwidths, support the 
expected voice, video, and data needed to coordinate 
activities at each stage of an exploration mission. In this 
paper, we discuss, in a generic fashion, how the 
architectural approaches and processes are being 
developed and used for defining a hypothetical 
communication and navigation networks infrastructure to 
support lunar exploration. Examples are given of the 
products generated by the architecture development 
process. 
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1 Introduction 

Communications and navigation networks are 
architected, designed, developed, and deployed based on 
the type of Space System of Systems (SoS) services 
needed. Communications and navigation networks of the 
future are being architected as an integrated set of new 
assets and a federation of upgraded legacy systems capable 
of routing IP traffic from any node to any other node on the 
network [1]. The utilization of upgraded legacy systems as 
part of the Network of Networks reduces both risk and 
cost. The Network of Networks will provide the inter- 
communication support for the Space SoS with each 
system utilizing a Local Access Network (LAN) for intra- 
communication support. IP provides a common routable 
end-to end capability. The use of registries and data 
dictionaries will provide a structure for the application 
layer system service interfaces and information exchanges. 
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This paper focuses on the Network of Networks 
and space communication links in support of the Space 
SOS services. NASA and the DoD have chosen IP coupled 
with modem high bandwidth microwave and optical 
communication links as the preferred technologies for 
providing the capabilities, flexibilities, autonomy, and end- 
to-end connectivity needed for space exploration and for 
supporting the warfighter in theater. There are certain to be 
significant advances in communications and navigation 
during the period of time for implementing the networks 
being defined by the architecture work. However, it is 
assumed, for this paper, that the advances in technology 
will be centered on improving information bandwidth with 
higher frequencies of transmission and improved 
techniques for modulation and autonomous network 
detection/connection and on improving IP performance and 
capability. Thus in the interest of describing a workable 
architecture, this paper does not attempt to assume 
technologies that might render IP obsolete. As it is, the 
networking packet protocol technologies (of nearly 40 
years ago) that became IP are advancing and becoming 
ubiquitous throughout all modes of communication. In 
addition, while the protocols become more complex as 
their capabilities are improved, processing and bandwidth 
also improve, resulting in higher overall network 
capability. It is not likely that IP will be displaced as a base 
technology in the timeframe for implementing the new 
networks. 

Figure 1 depicts a complex yet generic set of SoS 
node types that are expected in missions of exploration. 
The bottom of the figure indicates the Earth ground 
systems involved in support of exploration missions. 
Legacy systems shown include the Deep Space Network 
(DSN) and its control center, the Tracking and Data Relay 
Satellite System (TDRSS) Space Network (SN) and its 
controlling ground stations, and the navigation support 
center. The communication user control centers are shown 
for exploration missions, launch, and the International 
Space Station (ISS). A new distant IP network (DIN) 
control center (DINCC) and its ground stations (DGS) 
around the Earth are included in the diagram. The DGSs 
may be collocated at the DSN sites; however, they will 
likely require new system hardware and antennas to handle 
high communication data rates at long distances, new 
navigational services, and modern networking 
technologies. This new or highly modified legacy 
equipment must be dedicated full time to the exploration 
missions. These DGSs will handle direct communications 




Figure 1. General diagram of communication and navigation 
systems for future exploration. 

and control of communication relay satellites in orbit 
around the solar system body, as well as direct 
communications to any visible lunar or planetary surface 
communication terminal. 

As shown at the lower right in the figure, ground 
network sites handle capturing data from the crew launch 
vehicle before and during launch. Range Safety is also on- 
hand to send a flight termination signal in the event the 
launch goes astray. Additionally, a contingency voice 
system is available in the event normal communication is 
lost to the flight vehicle. 

The next level up, the Earth Orbit Systems, 
displays the communications needed at that level. 
Communication support needs are provided by the legacy 
TDRSS to support crew vehicle rendezvous with the ISS as 
the crew vehicle replaces the Shuttle in replenishing and re- 
crewing the ISS. The SN can also support the launch 
vehicle and crew vehicle during launch and rendezvous of 
the crew vehicle with the lander and Earth departure rocket 
to get ready for the transfer to the Moon, Mars, or 
elsewhere. Finally, the SN can support communications to 
the Crew return capsule during descent and landing. 

The third level (Transfer Trajectory Systems) 
shows a crew vehicle and lander in transit to the solar 
system object. The legacy DSN system can be modified to 
provide communications to support this phase and also the 
in-orbit crew vehicle and lander, shown before landing on 
the solar system object at level 4 (Lunar/Planetary Relay 
Orbit Systems). 

The fourth level also includes communication 
relay satellites (CRS) in orbit around the Moon or Mars. 

The CRSs support communication networking among 
surface nodes that are spread widely apart, such as 
astronauts, surface vehicles, and fixed habitats. They also 
provide high-rate trunks to route communications to and 
from Earth. The CRSs may include crosslinks among them 
to route networks from the backside to the front side of the 
body being explored [2]. 


The fifth level shows communications with the 
relay satellites, the Earth’s surface, and over the 
surface of the solar system body. The network 
over the surface will be of short range and limited 
by line of sight. However, the surface local area 
networks can be extended with towers similar to 
the architecture used in cell phone networks on 
Earth [3]. 

It is imperative to implement a SoS at the lowest 
cost of operations in an infrastructure for space 
exploration. Automation of ground systems, 
modernization of legacy assets, highly capable 
new assets that can be upgraded on the ground, in 
space, and on the surface of the Moon with 
software uploads, autonomy of operations of in- 
space communications assets, and fully IP- 
compliant networking technologies will be 
necessary in lowering the cost of operations [4]. 
Cost of development will not be insignificant, but 
in the very extended long-range plans being 
considered, the cost of operations will dwarf the 
cost of improvement in technologies. Much of the 
cost of the new technologies has already been 
carried by the commercial world. IP networking solutions 
are largely available for direct use. Work in this area does 
need to be done to handle IP addressing and networking 
among moving nodes and the distance time delays of space 
links. The space links will utilize an “extended IP” 
including UDP and the Delay/Disruption Tolerant Network 
standard under development to accommodate distance time 
delays. The rapid growth in the sizes of on-board memory 
and storage capabilities of space systems introduces 
another level of flexibility in scheduling and management 
of data and data transfers. The space links will utilize the 
predictability of satellite orbits along with navigation 
updates to manage antenna coordination and line-of-sight 
issues. The space link physical and data link layers will use 
the international CCSDS/AOS standards. The complexity 
of architecture for a Space SoS that provides 
communication and navigation services to astronauts and 
systems on the Moon become apparent in Figure 2 [5]. 
That figure illustrates several different types of 
communication links, including: the long-range high data 
rate trunk lines reaching from the DGSs to the CRSs [6] in 
lunar orbit (LCRS) and directly to the communication unit 
on the lunar surface (if that unit is in view of the Earth); the 
shorter range high data rate links from a LCRS to the 
surface communication unit or human occupied vehicles; 
the low data rate links from a LCRS’s multiple access 
subsystems to rovers, robots, science instruments, fuel 
extraction equipment (in-situ resource unit, ISRU), and 
astronauts performing extra vehicular activities (EVAs) on 
the surface; long range surface wireless wide area networks 
(WANs) that interconnect the surface communication unit, 
human occupied vehicles, rovers, robots, and network 
repeaters; and short range surface wireless local area 
networks (LANs) that interconnect astronauts on EVA, in 
vehicles, and in habitat, with each other and with rovers, 
robots and scientific instruments in close proximity. The 
acronyms DIN, DINCC, DGS, CRS, LCRS and their terms 
were fabricated solely to describe architecture in this paper 
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Figure 2. Illustration of the highly complex exploration networks. 


separately from existing legacy architecture and are not 
terms in general use. 

The LANs and WANs enable astronauts to 
collaborate on their activities by conversing, sharing their 
data, and sharing their vision by passing video among them 
while performing construction duties or while exploring. 
LCRS low data rate links enable communications among 
astronauts, vehicles, and other surface nodes that are 
widely spread apart beyond the line of sight of a WAN. The 
high data rate links enable the Earth operations centers to 
send voice, video, directives, commands, software, and 
data to surface nodes on the Moon. Likewise they enable 
the astronauts and other surface nodes to send voice, video, 
and science data from exploration activities; health data; 
navigational location coordinates; and engineering data to 
interested parties on the Earth. 

The complexity of communication on the Moon is 
further illustrated in Figure 2 by showing the types of 
networks that may reside within the communication relay 
and surface nodes. In the figure, the on-board 
communication subsystems and the control subsystems in a 
LCRS are interconnected with an IP-compliant network. 
Each subsystem has its own IP address dispensed by the 
central computer or server for 
configuring, operating, and 
monitoring each of the subsystems on 
the satellite. The satellites provide IP- 
compliant communication services on 
demand of the using nodes and 
autonomously reduce the need for 
continuous human operations and 
scheduling of the services they 
provide. The other surface nodes in 
the figure have their own controlling 
computers/servers and internal IP- 
compliant networks to interconnect all 


the subsystems within each node. The IP- 
compliant interfaces and routers, prevalent 
throughout the networks and user nodes, can 
route data throughout the infrastructure over 
the tortuous path between any two (or more) 
nodes on the Moon and/or Earth. 

The architecture must describe the joining of 
these disparate systems so they can 
intercommunicate and hand off 
communication links among each other as an 
exploration mission vehicle passes from one 
system’s domain to another’s. Furthermore, 
the communication services must join so that 
an exploration customer node may 
communicate with another node across 
system domains. The development process for 
this architecture must lay out the methods, 
operations, and interfaces needed to join 
together a federation of multiple, 
heterogeneous, legacy and new systems that 
incorporate networks at multiple levels and in 
multiple domains. 

The capabilities of the architecture, driven by 
emerging exploration requirements, will 
enable future astronauts to conduct space 
exploration, communicate with Earth-based 
scientists, excite future generations of explorers with high 
definition video to enable a virtual-presence participation 
in the astronauts’ exploration activities, and return safely to 
Earth at the end of the mission. 

2 Architecture Decomposition Process 

Standard system engineering methods and 
processes are used for defining and gathering capability 
requirements, and identifying a generalized initial 
architecture [7]. Additional steps include decomposing the 
architecture and using the Department of Defense 
Architecture Framework (DoDAF) operational, system, 
and technical view diagrams [8], and then refining the 
architecture as actual operational activities and functional 
requirements are identified during the development process 
[9] [10]. 

The architecture views convey the space 
communication and navigation network architecture to all 
the stakeholders (astronauts, exploration mission 
customers, system engineers, test engineers, international 
partners, potential equipment vendors, 
etc.) to assist them in verifying that the 
Space SoS will address their concerns 
or to help them understand the Space 
SoS and how they may take part in its 
implementation. 

The DoDAF methods of developing 
the architectural views were chosen 
for describing the space 
communication and navigation 
networks SoS because they are 
particularly suited to developing and 
defining complex communication 
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Figure 3, Architecture decomposition 


architecture and have been vetted by use in defining “as-is” 
and “to-be” communication architectures for major DoD 
communication projects. A hierarchical document and 
diagramming structure is used to present the complex 
communication and navigation network architecture in an 
efficient manner to a variety of users with differing needs. 
Thus, the amount of detail presented increases with each of 
the successive levels shown in Figure 3. The network 
architecture is described in terms of its operational, system, 
and technical attributes so that the user can gain insight into 
how it fulfills its mission objectives. The network 
architecture is decomposed into segments and elements. 
The purpose of the descriptions for each level is to show 
how segments and elements support the operational, 
system, and technical aspects of the architecture. 

3 IP-Centric Networks Architecture 

The communication and navigation network 
architecture must provide end-to-end communications, 
radiometric tracking, and timing synchronization services 
at low and high data rates to the crew vehicle and low data 
rate services to the crew launch vehicle 
during all mission phases. 

The communication and 
navigation network will consist of the SN, 

GN, and DSN legacy system elements, the 
new communication Intranet, and the 
network elements, previously identified by 
the fabricated acronyms: DIN, DGS, and 
the CRS in lunar orbit (LCRS) and later 
Mars orbit (MCRS), that will be added as 
space exploration extends into distant and 
deep space. Some system elements, such as 
the DSN and the mission control facilities 
at Johnson Space Center (JSC), have over 
25 years of legacy hardware, software, and 
policies. These networks are administered 
by different control center software systems 
and operational policies. To put together an 
IP compliant end-to-end management 
system with human rated real-time 
responsiveness requires stitching together 
numerous different administrative systems and domains 
with different policies, priorities, and management systems 
to form an integrated system that can plan, allocate, 
control, deploy, coordinate and monitor the resources of the 
network. Many of the legacy systems supporting existing 
space missions also have to evolve into the future 
architecture to meet the space exploration mission 
requirements. Currently, GN, SN and DSN do not provide a 
network interface to missions; however, they will need to 
extend network layer capabilities to space. Quality of 
Service (QoS) will need to be extended over multiple 
dissimilar domains. With human lives at stake on Mars or 
the Moon, automation, automatic error recovery, and local 
distributed control will have to be pervasive in the 
architecture. 

The capabilities of IP layer-based network 
architecture are illustrated in Figure 4. The naming of the 


network layers and the type of data carried over them are 
shown in the legend at the upper right of the diagram. 
Starting at the lower left is a scientific instrument that has 
its own simple internal network that begins at the top of a 
5-layer stack, the instrument controlling application layer. 
This network diagram is concerned with protocol 
processing, protocol interfaces, and transport mediums. 
While the protocols reside in system blocks, the internal 
subsystems are not discussed in detail. This diagram 
follows the passage of scientific, voice, and video data 
through protocol layers along a path that provides 
communication and networking service between the Moon 
and Earth. In the example, the astronaut or scientist would 
initiate a voice and video connection with the other. Then 
the astronaut can initiate the transport of the instrument 
data by pressing buttons on the instrument or by verbally 
commanding it to release its data to the scientist’s address 
on Earth. The diagram indicates the paths the instrument 
data takes through the protocol stacks, routers, and 
gateways to reach the scientist. These same network paths 
also handle the voice and video from the astronaut to the 
scientist in a separate parallel stream. The scientist, in turn 
converses with the astronaut on the return path. 


4 Propagating Navigation 
Architecture to Space 

A system of coarse and fme-grain navigation 
references will be integrated within the Space SoS to 
enable future space explorers and applications to 
autonomously access navigation and position services. In 
other words, astronauts must be able to “fly” crew vehicles 
and landers independently from an Earth-based mission 
control center simply because a mission to the Moon or 
Mars could result in a landing occurring out of sight of 
Earth. Furthermore, a landing on Mars will occur at a great 
distance from Earth, so far that real time communication 
from Earth to Mars is impossible. The astronauts will be in 
control of their safe landing on Mars, and the networks 
must provide the communication and navigation services to 
enable them to act autonomously. 



Figure 4, Layered IP Network Connects Ground and Space Together 





5 Applying DoDAF views 

A few typical DoDAF products are described 
below to illustrate the architecture. Other crosscutting 
views of the multitude of “as-is” legacy systems, “to-be” 
future systems, and future IP network decomposition views 
of the network layers and network-centric architecture may 
also be useful in describing the architecture. The 
architecture diagramming methods used range from the 
defined DoDAF graphical views to custom diagrams that 
use pictorial icons to represent nodal entities. 

The operational 
view, OV-1, shown in 
Figure 5, describes the 
overall operational 
concept for the 
architecture being 
described. Typically, the 
OV-1 is drawn with icons 
that represent the various 
system and operational 
nodes of that architecture. 

Here we use a simpler 
diagramming technique 
of using labeled boxes to 
indicate the nodes. The 
OV-1 shows the 
operational concept for 
interaction among the DINCC, the DGSs, the Exploration 
mission control center (MCC), the LCRSs, and the lunar 
surface nodes. Essentially, the figure indicates that any 
node may communicate with any other node in its vicinity. 
What is also implied but not clearly obvious is that the use 
of IP in the networks enables any node to communicate 
with any other node on the networks by routing the data 
through any of the intermediate nodes shown in the figure. 

Figure 6 is an OV-4 diagram that shows the 
relationships among the organizations involved with 
providing the communications and navigation services to 
the using nodes. The Exploration MCC shown at the top 



Figure 6. OV-4 Organizational Relationships 


represents the customer for the services. The customer 
interacts with the communication and navigation control 
center and management by requesting services to support 
its operations. The communication and navigation control 
center, in turn, requests network services from, and passes 
mission customer schedule information to, the DINCC and 
to the communication Intranet management center. The 
communication and navigation control center coordinates 
and schedules the network services with the DINCC that 
controls the DGS remote sites around the Earth and the 
LCRSs in orbit around the Moon. The DINCC also 

monitors the operation 
and health of the DGS 
site antennas and the 
LCRSs. The predictability 
and navigational 
verifiability of the LCRSs 
orbits and the periods of 
line-of-sight between the 
LCRSs and the DGS sites 
enable the possibility of 
autonomous operation of 
the Space links. Ideally 
the operation of the DGS 
antennas and the LCRSs 
would be fully 
autonomous with the 
DGS antennas 
maintaining continuous 
connectivity with the LCRSs through regular handoffs 
between stations as they come into and pass out of view of 
the Moon as the Earth rotates and as the LCRSs may 
become obscured by the Moon. Likewise, the LCRSs 
would maintain connection with Earth through the handoffs 
and would provide lunar surface users with service both 
scheduled and on demand of the user. The right side 
indicates the virtual communications paths among the 
Exploration MCC and the lunar surface nodes provided by 
the networks. Of course, the real path goes through 
multiple routing nodes in the network. The bottom of the 
figure shows that the lunar surface nodes, including the 
lunar surface terminal, can communicate directly with the 
LCRSs, for communicating with Earth and/or with other 
surface nodes. Surface network details are not shown 
because that network is expected to be fully autonomous 
and will need no external operations, except for 
maintenance that can be administered over the network or 
by astronauts on the surface. 

Figure 7 is an OV-2 diagram describing the 
operational node connectivity for the mission architecture. 
It is recommended that this diagram be drawn after the 
organization is defined in OV-4s and after the OV-5 
activities (not shown) are identified. Then the information 
that each organization needs to do its work can be 
identified along with the source of the information. The 
rectangular boxes in the diagram indicate the operational 
nodes. Inter-nodal connections are called needlines and the 
rounded rectangles display the information that must be 
passed from one node to another to enable each node to 
accomplish its operational tasks. For example, an astronaut 
who is communicating with a scientist on Earth may wish 



Figure 5. OV-1, Operational concept for lunar exploration 
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Figure 7. OV-2, Operational node connectivity diagram 


DIN system. Likewise, the LCRSs 
are aggregated as components of a 
larger LCRS Constellation. It’s 
possible to make this simplification 
if all the satellites in the 
constellation are identical. If not, 
they should be treated as unique 
individuals in the diagrams. The 
purpose of SV-1 is to identify all 
the interfaces among all the system 
nodes; here they are numbered. 
SV-1 leads into SV-2 (not shown), 
which is a similar diagram that 
shows the type of communication 
that occurs on each interface line, 
such as radio frequency band or 
network type. Ultimately, a system 
data exchange matrix (SV-6) is 
constructed that contains all the 
pertinent information that can be 
identified or decided during 
architecture development that 
passes over each interface. Included 
for each interface in the matrix is 
the needline and operational node 
information (obtained from the 
OV-2) that passes over the 
interface. It is from this matrix that 
the system engineers can extract the 
requirements for the interfaces. 


to show the scientist interesting mineral deposits. 
Such a communication path might be as shown in 
the figure where the astronaut communicates with 
voice, microscope video of the minerals, and data 
readout of a portable analysis device, such as an x- 
ray fluorescence instrument that is passed from the 
astronaut’s helmet radio to the vehicle shown. The 
vehicle aggregates of all the data in its vicinity and 
passes that to an overhead LCRS. The LCRS forms 
a larger aggregate of all the data passed to it and 
sends the data that is addressed to Earth on to an 
Earth ground station. The ground station extracts 
the IP data and sends it on to the Exploration MCC 
that, in turn, routes the voice, video, and data on to 
the scientist, who may be accessing her end of the 
connection over the Internet. Communication from 
the scientist is returned on the same path. Many 
possible communication paths among any and all 
nodes can be constructed from figures similar to 
the one shown. 

Figure 8 shows an example of the system 
interface diagram (SV-1) for the communication 
and navigation systems and services needed to 
support the activities of nodes on the surface of the 
Moon. This diagram uses UML component 
(rectangle with a small component artifact in the 
upper right comer) and system (block-shaped) 
icons to describe the Space SoS layout. The little 
rectangles indicate ports into and out of a system 
block. In the diagram, the ground stations and 
DINCC are shown as components of the larger 



Figure 8. SV-1 Systems and services interface description 
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6 Modeling, simulation and system 
engineering 

Extensive modeling and simulation is necessary 
for development and test of the interoperation among the 
networks and systems that is needed to save cost and 
increase reliability. 



Figure 9, Architecture modeling and testing process. 

A top-level view of the architecture-modeling- 
simulation process for the communications and navigation 
networks Space SoS is shown in Figure 9. The use of an 
architecture framework for the communications and 
navigation networks allows the creation of the architecture 
definition documents that contains diagrams and tabular 
data sets needed as input for the architecture modeling and 
analysis. Data traffic models and analysis is needed to 
optimize the data flow among the SoS, especially for the 
legacy space communications and navigation networks. 
The network simulation and emulation tools based on space 
and terrestrial protocols are being developed and used. 
Distributed simulation testbeds are being developed for the 
Space SoS during the formulation design phases. 

7 Conclusion 

Communication and navigation networks are 
essential elements of Space SoS. Their level of 
involvement can range from a few space links to a complex 
infrastructure or SoS. The challenges presented by the 
architecture of the communication and navigation networks 
are: 

• Implement high reliability, utilizing standard 
protocols; 

• Utilize the advantages of IP to provide transparent 
connectivity and interoperability among nodes on the 
networks; 

• Encapsulate IP over Space links maintaining 
International Compatibility; 

• Incorporate proven Space link technology (Upgrades 
Eegacy Network Technology); 

• Implement autonomous network management to 
reduce the cost of operations; 

• Utilization of Architecture Frameworks to provide 
operational, system, and network interface views of a 
complex Space SoS interconnected with a Network of 
Networks. 
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